By “integral sequence of commands” (“INSQs”) is meant herein a recurrent sequence of commands sent to a storage device from a host device, such as an MP3 player, a digital camera, or a computer system (e.g., a laptop), which sequence or storage device is associated with certain applications, for example with music playing, video recording, images capturing, etc., that have associated with them features, metadata or attributes such as packet size, timestamp, audio or video play back duration, data-read or data-write rate, address access or address continuity, etc. A host device sometimes sends an INSQ to a storage device with which it works regardless of which internal operation is currently executed by, or is in progress in, the storage device. This may detrimentally affect the performance of the storage device and the performance of the storage-host system as a whole.
The execution of some of the storage device's operations are to be avoided while an INSQ is executed (i.e., while the INSQ is “active”, “On”, or “in progress”), whereas some other storage device's operations may be beneficial or mandatory during the execution of the INSQ, as explained below. A sequence of commands that is not an INSQ is referred to herein as “sporadic sequence of commands”. That is, by “sporadic sequence of commands” is meant commands that are not considered by the storage device as part of a sequence of commands “known” to the storage device, unlike INSQs that are known to the storage device by being defined.
A storage device in a computer system can be regarded as rendering a storage service and, therefore, the storage device is expected to provide a good quality of service (“QoS”) even if it performs background tasks and executes internal operations such as “housekeeping” operations that are required for the storage device's normal operation.
Depending on the context of service given by a computer system (e.g., playing back an audio file, capturing images, copying data file, etc.) an operation executable by the storage device as a “background” operation can belong to a first set of internal operations, which is referred to hereinafter as an Extra-sequence (“ESQ”) operations group, or to a second set of internal operations, which is referred to hereinafter as an Intra-Sequence (“ISQ”) operations group.
By “ESQ operation” is meant herein a storage operation (e.g., static wear leveling) that should be avoided if an INSQ is in progress because the ESQ operation would have a detrimental effect on, or it would interfere with, or it would otherwise degrade, the performance of the storage device. For example, it would be beneficial not to execute static wear leveling operations while a music file is being played back from the storage device.
By “ISQ operation” is meant herein a storage, or storage-related, operation that is allowed or permitted to be executed during the execution of an INSQ because it has a positive contribution on the storage device's overall operation, or at least it does not interfere with or otherwise negatively affect the execution of the INSQ. In some cases, such an ISQ operation would, if executed, significantly improve internal efficiency of the storage device itself or the efficiency of the involved storage system as a whole. Operations made in preparation for the next, or for an expected, command (e.g., caching the next data) are exemplary ISQ operations. Sometimes, ISQ operations are even desired because, as far as the Quality of Service (“QoS”) and the overall storage device's efficiency are concerned, they have a positive contribution.
In respect of storage devices, ESQ operations may include operations such as archiving cached data, static wear leveling, flash folding (also known in the field of flash memory devices as “garbage collection”), ruggedization, and so on, which are known operations in the art of digital data storage management. ISQ operations may include: flash management operations; encryption/decryption of outgoing/incoming data; compression/decompression of outgoing/incoming data; anti-virus operation; defragmentation operation; ruggedization; backing up data; changing data format and so on, which are known operations in the art of digital data storage management. Thus, notably, whether a given operation is an ISQ or ESQ may depend on the operation (e.g., INSQ) in progress. The same operation may be an ISQ while one INSQ is occurring and an ESQ while another INSQ is occurring.
In order to improve the performance of storage devices (e.g., in terms of performance, power failure immunity, stable bit rate, etc.), execution of ESQ operations has to be coordinated with the execution of INSQ in such a way that ESQ operations are not executed while an INSQ is in progress. The reason for this is that executing ESQ operations while an INSQ is in progress can have an adverse impact on the storage device's performance, which may, for example, result in high latency, loss of data, or data corruption. ESQ operations have traditionally been initiated by host devices because of the presumption that only a host device can identify when an INSQ terminates and an ESQ operation can, therefore, safely be commenced.
In one prior art solution ESQ operations are allowed to be commenced by a storage device only after the device's host notifies the storage device that a current INSQ is terminating, or has terminated, and no new INSQ is scheduled for the time being, or for the next couple of seconds, for example. In other words, even though traditional storage devices are capable of initiating ESQ operations, they still need confirmation from their host device that they can do so. This constraint requires cooperation of the storage device's designer with the host device designer to allow the storage device's designer to schedule ESQ operations in such a way that they will not collide with an active host device's INSQ.
In another prior art solution ESQ operations are allowed to be initiated by a storage device autonomously, but they are not synchronized with the host device; i.e., ESQ operations are sometimes executed by the storage device at the wrong timing; i.e., at times when an INSQ is in progress and, therefore, should not be interfered with by ESQs.
It would therefore be beneficial for a storage device to be able to automatically identify, under the changing context of the service rendered by the involved storage system, if and when a storage background operation can be executed as originally planned or scheduled by the storage device, and if, when and which operations should be prevented, suspended or deferred until a currently executed INSQ is terminated, as well as if, when and which operations may or should be performed during INSQs execution.